Subject: Jim Cobban's e-mail on CP/ISR split with split DLC

From: "Marcia Peters (8-444-4380)" <[email-masked]>
Date: Wed, 20 Jul 94 11:04:24 EDT

Interesting contribution, Jim.  Would be nice to see the sequences in
Appendix S of the arch reference marked up with the modified signals.
Anybody willing to do a flow diagram for this?

--> Why is the CS algorithm for assigning TG numbers incapable of
    being distributed?

Marcia Peters, IBM

---

From: "jim (j.) cobban" <[email-masked]>
Date: Mon, 25 Jul 1994 11:25:00 -0400

In message "Jim Cobban's e-mail on CP/ISR split with split DLC", 

>Anybody willing to do a flow diagram for this?

Strangely enough I seem to have deleted my copy of my own submission.
Marcia, could you send me a copy back?

>--> Why is the CS algorithm for assigning TG numbers incapable of

There are 8 rules which the TG number assignment algorithm must obey.  The
easiest way to satisfy these rules is to perform the function centrally, as
described in the implementation model (p. 9-194 and 9-185 of architecture
reference).

 1) "a valid TG number is one that is greater than 0 and less than or equal
    to 255 and that is not currently being used to represent any other TG 
    between the two nodes."

    The current implementation is to maintain a central table which tracks
    all TG numbers which are in use to a given adjacent node.

    This could be distributed by:

    i.  Partition the TG number space.  When a Port is activated a portion
	of the TG number space is assigned to it for use if necessary.  A
	serious problem is that this would limit the number of Ports to at
	most 255.
    
    ii. Implement a signal by which the Port could request a unique TG number
	for a particular adjacent node from CS if it needed one.

 2) "The TG number that was used for a previous activation is reused if 
    possible."

    If the Port manager already has a previously obtained TG number for the
    adjacent node then it can carry out the TG number negotiation without
    requesting any assistance from CS. 

 3) "For new connections, numbers that have not been used for any TGs between
    the two nodes are preferred as TG numbers."

    Each Port manager sends an "Assign TG Number" request to CS which knows
    which TG numbers have not been assigned yet.

    "those that have been used for connections that are no longer active are
    not preferred but are acceptable as valid numbers."

    This situation, although unlikely since it implies that there are already
    255 distinct connections, past and present, with a particular adjacent
    node, complicates the algorithm.  One option is for CS to send a "Release
    TG Number" signal to a Port Manager for a TG number which it has reason
    to suspect, from its knowledge of link station states, is available.  If
    this assumption is mistaken, then CS would need to poll Port Managers
    until it found one.  The advantages of this technique, as opposed to the
    Port Manager explicitly informing CS of when a TG number is available,
    are:

    i.  It is invoked only in the unlikely case that all 255 TG numbers have
	already been handed out, rather than every time a connection goes
	down.
    ii. The Port Manager does not have to communicate with CS in order to
	perform the TG number negotiation on a recovered connection.

 4) "A TG number of zero is sent if the sender does not have a number stored
    either through system definition or a previous activation."

    This does not impose any restrictions on the algorithm.

 5) "... the node with the higher network-qualified CP name picks a valid
    number for the TG ..."

    This does not impose any restrictions on the algorithm beyond point 1s
    definition of valid.

 6) "If .. parallel TGs are *not* supports between the two nodes, the TG
    number is set to 0."

    This does not impose any restrictions on the algorithm.

 7. "... the number sent by the node with the higher CP name becomes the
    TG number ..."

    This does not impose any restrictions on the algorithm.

 8. race condition

    This does not impose any restrictions on the algorithm except the
    caveat for avoiding conflicts with rule 2.

Therefore the statement that the TG number assignment algorithm must be
centralized is clarified.  There must be a central database which tracks
which TG numbers are assigned for each adjacent node.  However the actual
mechanics of the negotiation, and therefore the XID negotiation itself, may
be distributed.  

The following signals are proposed for this aspect of communications between
CS and the Port Manager:

 Assign TG Number - sent from Port Manager to CS. The request carries two
		    parameters, the CP name of the adjacent node, and the TG
		    number proposed by the adjacent node (possibly zero).
		    The response either carries the TG number assigned by
		    CS or an indication to fail the XID negotiation.

 Release TG Number- send from CS to Port Manager.  The request carries the
		    CP name of the adjacent node and the TG number which CS
		    wishes to reuse.  If the connection is inactive Port
		    Manager sends a positive response.  Otherwise it sends a
		    negative response and CS polls another Port Manager.

Of course splitting CS from Port Manager would require additional signals
such as a superset of the ACTIVATE_PORT signal currently sent to DLC, QUERY
signals, and so on.